communityleadershipsummitfandomcom-20200213-history
Giving Back
Session Notes: Giving Back Session Room: Table 3 Time Slot: 11AM on Saturday Organizer: Jared Smith Note-taker: Richard Esplin Notes: *Put on the table for another session the question of how to convince the business to invest in the community *Let's define community: it isn't a mailing list, it is treating people as peers on a project. A community is something beyond a users group. It is when people come together to talk to each other, and not to talk exclusively with you. Questions: *Where should my team get started in building a new community **Biggest problems are cultural: need to get comfortable with the fact that you are giving away IP. Get the lawyers involved: OSS legal consulting project. **There is a fear that a lot of things can go bad when we do things in the open. Need to quantify what your risk tolerance is to have a clear conversation. *What should be given back? Competitive advantage is off the table. **Most open source developers are not in software companies where it is their competitive advantage. **We need to define our competitive advantage in terms other than intellectual property: relationship, internal processes, services. *What do folks in the open source community want from a company backer? **A clear way to contribute back. **Open communication Take-aways: *Open Source is not just software, it is about relationships. And a lot of the conversation is around how much to formalize that relationship. *Be clear about what is intellectual property and what isn't. Be clear on what IP is differentiated; most of it isn't. *Company culture is a handicap: need to have an absurdity filter--someone in power that can say "we aren't going to worry about that concern" *Emphasize that open interactions lowers a lot of risk because problems are identified early before they become gigantic. Your mistakes will become public anyway. *For a community contributor, money comes second. People are interested in the experience and interactions of community participation. *Need to get to know your community better. What do they really need? Better tools, another developer, marketing? As a company, you can step in and offload that. *Diversified contributions. People are tired of being asked to be an ATM, and people are tired of feeling like they can only ask for money. Community management is about finding the right people to fill niche skills. *At Blue Host, we can give a lot of metrics and feedback to our upstream open source communities. Blue Host Open Source Solutions project. We provide the relationships to our developers to enable them to contribute back. *Listen to the upstream community about what do they need. Learn to contribute in a way that they can use. *Define in advance how you are going to accept contributions--how can you reduce the friction to getting something contributed? *Finding a good community manager is important, and really hard. Co-opting a top committer is the best way. *Two models: have a transaction in order to build a relationship, or build a relationship in order to justify transaction. Open source usually wants the transaction first. *Find a creative way to say yes: have someone assigned to get contributions up-to-scratch for committing. *Be careful in rewarding contributors. If you create a distinction of haves / have-nots it could de-motivate your community more than you expect. Action Items: *None